Skip to main content
`Ctrl`+`K`

# `config.yml`

YAML File | `config.yml`
Loader Class | `yaml.SafeLoader`
Dumper Class | `ng911ok.lib.config_dataclasses.ConfigDumper`
Python Module | `ng911ok.lib.session`
Python Variable | `config`

The schema of an Oklahoma-Standards-Compliant NG911 geodatabase is described by the `config.yml` file.

## YAML Structure

### Top-Level Keys

`geodatabase` | Mapping describing miscellaneous properties of the geodatabase as a whole.
`domains` | Sequence of mappings, each defining the properties of one geodatabase domain.
`fields` | Sequence of mappings, each defining a field used by NG911 feature classes.
`feature_classes` | Sequence of mappings, each defining the properties of one NG911 feature class.

### Tags

Constructors are registered in `ng911ok.lib.session` and `ng911ok.lib.config_dataclasses`.

`!GDBInfo` | Applied to the top-level `geodatabase` key.
`!CompleteDomainList` | Applied to the top-level `domains` key.
`!Domain` | Indicates a domain definition under the `domains` key.
`!CompleteFieldList` | Applied to the top-level `fields` key.
`!Field` | Indicates a field definition under the `fields` key.
`!FeatureClassList` | Applied to the top-level `feature_classes` key.
`!FeatureClass/*` | Series of tags each indicating a feature class definition, where `*` is a placeholder for a PascalCase name of a feature class.

### Anchors

`&required_dataset_name` | Name of the required feature dataset. Intended for use in the `dataset` keys of mappings under the top-level `feature_classes` key.
`&optional_dataset_name` | Name of the optional feature dataset. Intended for use in the `dataset` keys of mappings under the top-level `feature_classes` key.

#### Domain Anchors

Every domain under the `domains` top-level key should have an anchor whose name is equal to the `name` key of the domain with which it is associated. Every use of the `!Domain` tag in `config.yml` should also have such an anchor. These anchors are intended for use in the `domain` keys of mappings under the top-level `fields` key.

#### Field Anchors

Every field under the `fields` top-level key should have an anchor whose name is equal to the `role` key of the field with which it is associated. Every use of the `!Field` tag in `config.yml` should also have such an anchor. These anchors are intended for use in the `fields` keys of mappings under the top-level `feature_classes` key.

## Python Implementation

### The `config` Variable

The module `ng911ok.lib.session` provides the `_NG911Config` class and its only instance, `config`, exposes the data stored in `config.yml`.

Constructors for `!CompleteDomainList`, `!CompleteFieldList`, `!FeatureClassList`, and `!FeatureClass/*` are registered in `ng911ok.lib.session`. The remaining tags are implemented as subclasses of `yaml.YAMLObject` in `ng911ok.lib.config_dataclasses`.

### Namespace Classes and `fctypes.py`

The `!FeatureClass/*` constructor returns an instance of `ng911ok.lib.config_dataclasses.NG911FeatureClass`. The type of the returned instance’s `fields` attribute depends on the tag’s suffix (the part after the slash, such as `AddressPoint` in `!FeatureClass/AddressPoint`). More specifically, that attribute will be an instance of the class `NG911<tag_suffix>FieldNamespace`, where `<tag_suffix>` is the suffix previously described. All such classes are defined in `ng911ok.lib.fctypes`.

The `fctypes` module is unique in the `ng911ok` package in that it is programmatically generated. It should not be manually edited. If some sort of change is necessary, it should be accounted for in `generate_fctypes.py`, which is responsible for generating the code in `fctypes`. Having classes that correspond to the YAML helps provide for type-checking and autocomplete in IDEs.